Ref: #1250 a Proposal to Define Some Container-Related Terms

I think this definition of indexable sequence (or collection) is not right.

#1250 has a renaming and different definition:

An indexable collection is a collection in which any given element can be accessed via an index, and a contiguous subset of elements—referred to as a slice—can be denoted via a range.

#1250 also defines collection:

A collection is an ordered set of zero or more collection elements that can be used in a polymorphic way. Often, the elements are of the same data type such as int or string. Sometimes the items derive from a common type; even deriving from the most general type, object.

I”m not sure where the “polymorphic” in the collection definition comes from, but it does correctly drop the “same type” of indexable sequence.

The term “ordered set” allows the reading that it is the elements that are ordered (as in [partially] ordered sets and SortedSet<T>), which they need not be. It is the indicies that are ordered… usually.

System.Index indicies by themselves are actually not ordered and the type does not implement IComparable<Index> just IEquatable<Index>. They are ordered only w.r.t a particular collection, which has some Length, this is because indicies can be end-relative.

Maybe:

Or something like that…

This is similar to the definition in #1250, but without the underlying definition of collection (for now…).

The definition of range here doesn’t address that a C# a..b Range does not include b, or that a C# Range may not be a contiguous set of ordered indices (consider 1..^Int.MaxValue which is a valid Range to construct but useless to use!).

So there is a disparity between the term “range” and C#’s type Range– that might be confusing…

I'd suggest either "sequence" or "collection" instead of "set" as well. Likewise "subsequence" instead of "subset"?

[Replacement comment, I hit add too quickly]

@jskeet dropping set is a good idea.

But are we taking about sequences, which by (English language) definition are ordered, or collections which are not?

Do we need to make it clear that any ordering here comes from the index type being ordered, not the elements?

Indices do not need to be ordered per se, but a range of indices implies ordered indices, and indexable sequence/collection is being defined to be used by ranges.

Which gives us:

Too detailed/convoluted?

Question under discussion: does Dictionary<TKey, TValue> count as an indexable sequence? (Or rather, do we want it to?)

Interesting types:

• int
• System.Index
• long (just for arrays)

We may want to limit this to integer-based indexes.

How about a Dictionary<int, string>?

We also had some discussion about what "ordered index" means (especially when System.Index isn't inherently ordered).

Hmmm…

struct Plank
{
   int Length { get; }      // all measurements in mm
   int Width { get; }
   int Thickness { get; }
}

A single plank is countable (in the sense intended)?

Maybe:

with a x-ref to wherever collection gets defined (see #1250).

Note: Qualifying, “collection type”, also avoids integers not be countable – which could otherwise confuse the numerate 😉

Note: This doesn’t address “In case both Length and Count are present, Length will be preferred.” found here.

While having general terms is good this particular term currently only exists to be referenced in the new clauses “Implicit Index support” and ”Range Index support”. It would be better to move this to down to those two clauses, possibly even removing it as defined term altogether.

Let's move this to the general clause of indexable sequences, where we're introducing other terms that are only relevant to that. (This doesn't address the plank example, but at least suggests where countable types are relevant.)

@jnm2 – 0 through N for ^ to allow for ^0? Otherwise 👍

No, a slice might be obtained using a range – or it might fail, a range can be constructed using the range operator…

TBD: Wordsmith a suggestion

I agree with @jnm2 here – C# doesn’t have jagged arrays per se, it supports single-dimensional arrays where the element type can be an array which:

can be used to represent “jagged arrays”. [§17.1]

I would just drop the reference (and the !), x-ref fixed as per @BillWagner comment below:

[Replaced] (My fears were justified)

For the refness question, maybe:

The type has an accessible instance indexer taking a single parameter of type int without any associated parameter_mode_modifier.

Converting descriptive to specification language:

Further to my last comment, there is no context here as to why either Length or Count should be used at all – there is no mention of GetOffset is there is in expressions.md line 2242. And as commented on the latter, surely we don't need this stuff in two places?

@jnm2 – maybe “straightforward” which doesn’t carry the same risk of offense as “simple”, or may be:

Wordsmith away folks!

If a different method is being used for arrays then it needs to be specified in normative text, not as an informative note.

Use ref_kind, I suspect it just predates this?

I'd suggest either "sequence" or "collection" instead of "set" as well. Likewise "subsequence" instead of "subset"?

Does a slice have to be of a countable type? You can write an uncountable type with an indexer accepting a range, and make it fail at execution time if either end of the range is "from the end".

I agree it will usually be of a countable type, just trying to explore...

Should we also say that these arrays are countable as well?

@jskeet – I’ve now added that to the suggested definition of slice.

And countable? (I won't keep adding this...)

@jskeet – Once we’ve the definition of indexable narrowed down to what is needed for this feature then countability (if it still exists as a concept) will be implied as using an Index relies on it.

Aside from anything else: I think these should refer to parameters, not arguments. There's no such thing as an optional argument, only an optional parameter.

I think this should probably be rewritten anyway, in terms of "behaving as if an instance indexer member is provided".
(Again, this is up for discussion - basically, do we expect that to be in the emitted IL, like a default instance constructor is? I suspect not.)

(To avoid any suspicion of boxing.)

(Or let's clarify in a different way. The fact that range_expression uses range_expression make this more confusing.)

Is this definitely correct? That suggests 0 .. 4 .. 5 would be valid, because 0 is a valid range expression, and so is 4 .. 5.

I think I'm missing something here.

I haven’t yet taken a look at the grammar, but yes that looks wrong.

This clause & its subclauses might be better after §15.9 Indexers, or as a subclause of §15.9.

Punt on this until the rest is ready.

The definition of indexable sequence, both original and revised versions, do not fix the type of the index. Here the type is fixed to being an integer number (it does not state the actual type).

How does this mesh with the “behave as if” behaviour specified in the new clause Implicit Index support (classes.md, line 5594)?

This version mentions GetOffset, but are we requiring that it be called or that an implementation may “behave as if” it is? Elsewhere in the Standard there are passages where behaviour is defined to be the “equivalent of executing the following code” (or words to that effect), would that pattern be better here?

This check on P being valid is occurring after the conversion of Index to int which requires P…

I think the valiant attempt to interweave Index and Range is currently a bit hard to follow, well at least I've had to keep re-untangling it as I check the semantics. I think separating out integral, Index and Range cases a bit more would help, I might back it back before the meeting to make a suggestion…

I think by this list, the following should not error, but it does:

var dict = new X();
dict[^1] = "";

class X : Dictionary<int, string>
{
}

Here's an unexpected example:

public struct Int32OrRange
{
    public static implicit operator int(Int32OrRange index) => 0;
    public static implicit operator Range(Int32OrRange index) => new Range(0, 0);
}

string[] array = { };
Int32OrRange x = new();
var result = array[x];

That compiles, and uses the conversion to int. If you remove the conversion, it still compiles, and uses the conversion to Range. I'd have expected the first to compile because neither int nor Range is better than the other.

I checked with the compiler team. The roslyn implementation ranks single argument indexers in the following order:

• int
• uint
• Int64
• UInt64
• Index
• Range

I wouldn't expect that to change, so we'll have to come up with normative rules that match that behavior.